home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1158 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  8.0 KB
  1. Date: Sat, 30 Jul 94 02:50 CDT
  2. From: ekl@sdf.lonestar.org (Evan K. Langlois)
  3. To: gem-list@world.std.com
  4. Subject: Re: app_defs.sys
  5. Precedence: bulk
  6.  
  7. Someone is gonna dump me from the list for adding too much to it, but ..
  8.  
  9. ========================================================================
  10. How about for terminal programs?  This is one I've struggled with
  11. myself.  Most terminal programs CRAWL under MultiTOS for two reasons:
  12. 0-lenght timers slow everything down, and GEM doesn't get back to the
  13. program fast enough when catching characters from the modem so typing
  14. comes out unbearably jumpy.
  15. ========================================================================
  16.  
  17. I know a really good way, but it needs multiple threads of execution.
  18. (You use tfork() in the MiNTLIB) and you also need Fselect (or some
  19. similar method of blocking for modem IO). 
  20.  
  21. Now, I'm bassing this code off the assumption that a thread can call
  22. the AES to get a rectangle list and draw its own text since it shares
  23. the parents memory and app_id.
  24.  
  25. Now, here is the structure.  Thread 1 - this is the main code that
  26. calls evnt_multi() and waits there.  It doesn't use any timer events.
  27. If it reads any keypresses, they are sent directly to the modem.
  28. This thread blocks when you don't have any keyboard events or other
  29. GEM events.  Redraws can be done with shared memory.
  30.  
  31. Thread2 - this waits on any number of file handles, although it only
  32. needs to wait on one (optional timeout).  It blocks until the 
  33. device is has data ready to be read or written.  When Fselect returns,
  34. Fread as much data from the file handle (raw mode) as you can,
  35. with standard GEMDOS Fread() with a whatever maximum you like (you
  36. can use whatever you like, or dynamically change the size if Fread
  37. reads your entire buffer, then double the size so it doesn't fill
  38. up anymore!)  After you read all the data, update your windows
  39. internal and external structures.  Key events are still echoed
  40. directly to the modem, even during redraw.  Once you've done the
  41. update, call Fselect again and wait for more modem data.  This thread
  42. will block when there is no modem IO to read.
  43.  
  44. You can make things a bit more complex by making the display
  45. "thread" separate from the modemIO/Fselect thread and just
  46. use Pmsg() to pass events back and forth.  This also allows
  47. you to do a local echo by passing a message for keyboard
  48. events, and you can fully encapsulate the "Window" as a
  49. true active object that sits, waiting for events, and you
  50. can do synchronizing between the threads too, like if you
  51. don't want the IO thread to continue until you finish updating
  52. your window (so you won't get lots of Pmsg's in a row) then
  53. you can have that thread wait for a reply.  I can elaborate
  54. on this model more if you like.
  55.  
  56. In either of the two models above, all threads will block when
  57. needed and can operate independantly of the other so you don't
  58. have to wait for data being sent just to recieve data.  For
  59. lots of data, Pmsg() that passes a pointer to the data is probably
  60. best, but you can always make the window "Object" open a pipe
  61. and stuff vt52 data into it and let the window code worry about
  62. the rest :-)  The first is pretty easy to write if you already
  63. have the window display code written.  The second takes a bit
  64. more tweaking, but its very expandable and flexible.
  65.  
  66. ========================================================================
  67. I figured that things would work a bit better (and cooperate with the
  68. rest of the system) if I used a longer timer.  Things speed up a bit, but
  69. typing us just as jumpy (when your host is the one who is echoing).
  70. Any suggestions?
  71. ========================================================================
  72.  
  73. Optimize your redraw code to death, use jump scrolling, use large
  74. buffers.  I'm not sure if you can set modem IO to raw mode without
  75. MiNT.  I think Fread will just use cr-mode and will wait until it
  76. reads an end-of-line character.   With MiNT, you set the file handle
  77. to raw mode and you can get masive amounts of data at once (saves
  78. all that time calling the bios at 1920 times per second!)
  79.  
  80. Have you achieved the speed of Connect?  If Connect threaded I don't
  81. think there would be a limit to its speed :-)  Then again, maybe
  82. it does use RAW mode .. I've never tried Connect without MiNT.
  83. Timer events really suck because you are trying to control the 
  84. multitasking without sufficient information.  Using blocking threads
  85. seems to work quite well.
  86.  
  87. In fact, I'm using a double-threaded terminal now, but its unbuffered.
  88. I still use BIOS (I'll change that).  And I didn't feel like writing
  89. code for windows, fonts, and scrollback, so I use BIOS output and
  90. let TOSWIN do the work.  However, the overhead of TOSWIN made my
  91. first attempts, using Bconstat() a total failure!  It wouldn't
  92. keep up with 2400!  Threading made things VERY fast.  Just as fast
  93. as Connect actually, or almost since JUMP scrolling can be VERY
  94. jumpy if I click a mouse button and hold it (locking the window
  95. update).  I've done some tests piping data and such, but without
  96. a faster modem I can't make a good comparison.  But I rewrite for
  97. Fselect/Fread instead of BIOS it will be MUCH faster.
  98.  
  99. ========================================================================
  100. I don't want app_defs.sys turning into another win.ini.  When you install
  101. a Windoze program, it adds all this CRAP to your system files like
  102. win.ini, etc., and then when you want to remove the app, you still have
  103. this crap in your win.ini file.
  104. ========================================================================
  105.  
  106. A de-installer just looks for AppName* and deletes those lines.
  107. In fact, a single Install/De-Install proram that copied files, added
  108. and removed icons from the desktop files, and deleted entries from
  109. app-defs.sys would be quite handy, especially if it decompressed
  110. files too before installing them!  You wouldn't modify app-defs
  111. on installation.
  112.  
  113. ========================================================================
  114. My library can now do dragging of active and passive sliders in
  115. background windows, as well as buttons.  It also handles all of these
  116. things using the rectangles list so they come out properly if partially
  117. obscured.
  118. ========================================================================
  119.  
  120. Hmm .. how?  You don't get any events until you release the button!
  121. What sort of hackery is this?   Could you post the code?  Or email
  122. it to evanlang@uss.lonestar.org?
  123.  
  124. ========================================================================
  125. How is a menu structured?  It seems kinda odd the way the objects are
  126. arranged in it... boxes, iboxes, etc.  What's a sure way to just go
  127. through JUST the titles one at a time?  How do I get the first title?
  128. Require the programmer to pass the object number of the desk title?  That
  129. would make it easiest.
  130. ========================================================================
  131.  
  132. If you want to disable menus for modal dialogs, the easiest way is to
  133. have 2 menu bars.  One normal, and the second with just the Desk Menu
  134. enabled and the rest of the titles disabled.  Then you can swap
  135. menu bars .. all the user sees is the titles de-selecting.  As for
  136. just the titles, they are all children of the menu bar.  Here :
  137.  
  138.                   ROOT (G_IBOX)
  139.                  /           \
  140.         BAR (G_BOX)        DROPDOWNS (G_IBOX)
  141.            |                    /      |     \
  142.        ACTIVE (G_IBOX)     G_BOX     G_BOX   G_BOX
  143.       /      |        \
  144.   G_TITLE   G_TITLE  G_TITLE
  145.  
  146.  
  147.  
  148. The object structure has all the child pointers and indexes and
  149. stuff that you need.  Once you find the ACTIVE G_IBOX, all
  150. its children are your menu titles, in order too I think!
  151.  
  152. And yes, you could just pass the object number of the TITLE.  That
  153. is easier than any other method, except swapping menus, but using
  154. the object index and the objc_ functions is a better solution.
  155.  
  156. ========================================================================
  157. You have an Atari book that needs to be published?  Two Worlds Publishing
  158. can do it for you.  :)
  159. ========================================================================
  160.  
  161. The internet frowns on commercial advertising .. can you have a
  162. shareware publishing company?
  163.  
  164.  
  165.  
  166.  
  167.